home *** CD-ROM | disk | FTP | other *** search
/ SuperHack / SuperHack CD.bin / documentos / ircwar.TXT < prev    next >
Text File  |  1999-05-11  |  35KB  |  718 lines
  1.                    Tßcticas de guerra en el IRC v.0.99a+
  2.  
  3.                     Por:  RoMaN SoFt / LLFB    (30/7/97)
  4.  
  5. ______________________________________________________________________________________________
  6.  
  7. La distribuci≤n de este documento es "libre", con la ·nica condici≤n de
  8. informar al autor en caso de subirlo a alg·n ftp site o pßgina web. La
  9. misma restricci≤n se aplica a cualquier otra forma de difusi≤n p·blica
  10. (revistas, news, Θtc).
  11. ###############################################################################################
  12.  
  13. ---------------------------------------------------------------------------
  14.  
  15.  
  16.  
  17. 0.- Contenido.
  18.  
  19. 1.- Introducci≤n.
  20. 2.- Principios.
  21.   2.1.- C≤mo funciona una red IRC.
  22.   2.2.- Conseguir op sin que nadie te lo de.
  23.   2.3.- Otras formas de conseguir op.
  24.   2.4.- Bot de servicio.
  25. 3.- Ataques.
  26.   3.1.- Flood.
  27.   3.2.- Nick collide.
  28.      3.2.1.- Split server collide.
  29.      3.2.2.- Lag collide.
  30.   3.3.- Nuke.
  31.      3.3.1.- ICMP nuke.
  32.      3.3.2.- OOB nuke.
  33.   3.4.- Ping.
  34.   3.5.- Ssping.
  35. 4.- Spoofing.
  36. 5.- Resources.
  37. 6.- Agradecimientos.
  38. 7.- Notas finales.
  39.  
  40.  
  41.  
  42. 1.- Introducci≤n.
  43.  
  44.  Ultimamente la guerra en el IRC es, por desgracia, algo bastante com·n.
  45. Conviene, a lo menos, estar informado de las distintas tΘcnicas que se
  46. suelen usar para "luchar", aunque sea simplemente para detectar que te
  47. estßn atacando y saber c≤mo lo estßn haciendo. No es mi intenci≤n
  48. profundizar demasiado en el tema aunque intentarΘ detallar algunos puntos
  49. que considere convenientes.
  50.  
  51.  Todo lo que aquφ se hable es extensible en general a cualquier red IRC. No
  52. obstante en algunos casos muy particulares me referirΘ a la red IRC hispana
  53. ("*.irc-hispano.org"). Ni que decir tiene que la informaci≤n que se
  54. proporciona aquφ es con fines educativos; en ning·n caso debe ser usada
  55. salvo en circunstancias excepcionalmente justificadas. Un uso abusivo puede
  56. significar una k/g-line totalmente merecida. Yo no me hago responsable de
  57. un posible mal uso de esta info.
  58.  
  59.  
  60.  
  61. 2.- Principios.
  62.  
  63.  Muchas veces el objetivo de un ataque no es otra cosa que hacerse con un
  64. canal ("tomarlo"). Esto es relativamente fßcil y hay diversas tΘcnicas para
  65. ello. El objetivo es hacerse con el op en el canal. Los medios: tu
  66. inteligencia y astucia... ;-)
  67.  
  68.  
  69. 2.1.- C≤mo funciona una red IRC.-
  70.  
  71.  El servidor de IRC propiamente dicho no es mßs que un programa corriendo
  72. en background (un daemon) en una mßquina determinada (en Unix correrφa el
  73. "ircd"). Los usuarios se conectan a dicha mßquina y acceden al servidor en
  74. forma de clientes.
  75.  
  76.  Una red IRC se compone de varios servidores corriendo en paralelo y
  77. enlazados entre ellos, de forma que se mantegan comunicados (puedan
  78. intercambiar mensajes entre ellos). Cuando un usuario se conecta a un
  79. servidor determinado, Θste (el servidor) lo notifica a los demßs servidores
  80. que forman parte de la red IRC. Igualmente, cualquier otra acci≤n es
  81. notificada a todos los servidores, de forma que Θstos actuan como una
  82. unidad. De esta forma el usuario se deja ver en todos los servidores aunque
  83. fφsicamente s≤lo estΘ conectado a uno. Esto permite tener muchos usuarios
  84. repartidos por diferentes servidores pero que virtualmente es como si
  85. estuvieran todos en uno s≤lo.
  86.  
  87.  La estructura de la red IRC es en forma de ßrbol (es decir, no puede haber
  88. bucles, o "caminos cerrados": partiendo de un nodo no se llegue por ning·n
  89. camino otra vez a dicho nodo) aunque un tanto especial: cada nodo se ve a
  90. sφ mismo como el nodo raiz de la red. En la "literatura" esto se conoce
  91. como "spanning tree". Un ejemplo de red podrφa ser:
  92.  
  93.  
  94.  
  95.                            [ Server 15 ]  [ Server 13 ] [ Server 14]
  96.                                  /                \         /
  97.                                 /                  \       /
  98.         [ Server 11 ] ------ [ Server 1 ]       [ Server 12]
  99.                               /        \          /
  100.                              /          \        /
  101.                   [ Server 2 ]          [ Server 3 ]
  102.                     /       \                      \
  103.                    /         \                      \
  104.            [ Server 4 ]    [ Server 5 ]         [ Server 6 ]
  105.             /    |    \                           /
  106.            /     |     \                         /
  107.           /      |      \____                   /
  108.          /       |           \                 /
  109.  [ Server 7 ] [ Server 8 ] [ Server 9 ]   [ Server 10 ]
  110.  
  111.                                   :
  112.                                [ etc. ]
  113.                                   :
  114.  
  115.  
  116.  Cuando se rompe uno de los eslabones (links) que unen 2 servidores el
  117. conjunto se divide en 2 subconjuntos, los cuales intentarßn seguir
  118. funcionando normalmente aunque de forma aislada. Esto es, cada subconjunto
  119. permanece operativo y mantiene la comunicaci≤n entre los servers
  120. pertenecientes a dicho subconjunto. Pero por razones obvias los servidores
  121. de un subconjunto no ven a los del otro y viceversa. Esta situaci≤n se
  122. conoce como net-split.
  123.  
  124.  En una sesi≤n normal de IRC esto lo verφamos:
  125.  
  126. [1:23] *** Case_Zer0 has quit IRC (fuego.irc-hispano.org
  127. io.irc-hispano.org)
  128.  
  129.  Esto indica que se han spliteado los dos servidores indicados entre
  130. parΘntesis y que a consecuencia de ello el usuario Case_Zer0  [ hi Case ;-)
  131. ]  ha salido "de nuestra red IRC" (lo que estß ocurriendo es que se
  132. encuentra en el otro subconjunto de servidores: a todos los efectos es que
  133. como si se encontrase ya en otra red IRC).
  134.  
  135.  Cuando el enlace caido se recupera (i.e. se reestablece la comunicaci≤n
  136. entre los servers spliteados) se habla de net-merge. Esto se verφa en la
  137. sesi≤n anterior como un "join" por parte del usuario que estaba en el
  138. servidor spliteado (tanto el quit como el join anteriores son mecanismos
  139. del propio IRC, es decir, el usuario anterior no dio ninguna orden de quit
  140. ni de join, es transparente a dicho usuario).
  141.  
  142.  Hay programas que detectan y avisan cuando se produce alg·n net-split o
  143. net-merge: son los denominados "link-lookers", y su utilidad es bastante
  144. obvia.
  145.  
  146.  Por ejemplo, si el enlace dibujado en rojo (enlace server 2 <-> server 5)
  147. cayera, el servidor 5 estarφa aislado de la red. Los usuarios de dicho
  148. servidor dejarφan de ver a todos los demßs pertenecientes a servidores
  149. distintos, y al contrario. Se dice que el servidor 5 estß spliteado. Es
  150. fßcil reconocer a un servidor en esta situaci≤n: si entras en una red a
  151. travΘs de un determinado servidor y te encuentras a muy poca gente es muy
  152. normal que se deba a que estß spliteado de la red.
  153.  
  154.  Otra posibilidad es que el enlace azul (3 <-> 12) cayera. En este caso el
  155. servidor 12 se splitea de la red, pero tambiΘn lo hacen los servidores 13 y
  156. 14 indirectamente, por conectarse a travΘs del primero.
  157.  
  158.  Para una informaci≤n completa del funcionamiento y estructura de una red
  159. IRC, y del protocolo subyacente ("Internet Relay Chat Protocol") os remito
  160. al RFC1459.
  161.  
  162.  
  163. 2.2.- Conseguir op sin que nadie te lo de.-
  164.  
  165.  Cuando alguien se une a un canal donde no hay nadie (hace un /join #canal)
  166. el servidor supone que se trata de un nuevo canal y le da op a dicho
  167. usuario. Se dice que ha creado un canal. Vamos a aprovechar esto para
  168. hacernos con el op en un canal ya existente. ┐C≤mo? Fßcil: solo hay que
  169. aprovechar un net-split. Los pasos serφan los siguientes:
  170.  
  171.  - Esperar un split (lo podemos detectar con un link-looker).
  172.  - Entrar (conectar) al servidor spliteado.
  173.  - /join #canal (donde canal es el canal donde queremos conseguir op).
  174.  - El server crearß un nuevo canal y tendrßs el op.
  175.  - Esperar a que se deshaga el split.
  176.  
  177.  Si "hay suerte" (leer mßs abajo), al deshacerse el split conservaremos el
  178. op en los restantes servidores (el servidor spliteado se encarga de dar las
  179. ≤rdenes correspondientes). Entonces se dice que hemos llevado a cabo un
  180. "net-hack". Los usuarios presentes en el canal en el que hemos llevado a
  181. cabo la acci≤n verßn algo como:
  182.  
  183. [1:41] *** irc.i3d.es sets mode: +o RoMaNSoFt
  184.  
  185. (donde el servidor que nos da op es el que antes estaba spliteado).
  186.  
  187.  Esto no siempre funcionarß porque hay aspectos que todavφa no he
  188. comentado. Paso a explicar el procedimiento y comentar algunos puntos
  189. negros. Supongo que habrΘis comprendido el procedimiento; es muy simple:
  190. aprovechar que el servidor spliteado no ve a los usuarios de otros
  191. servidores y por tanto al canal previamente creado. Esto presupone que no
  192. hay usuarios del servidor spliteado en el canal (en este caso no
  193. funcionarφa) porque en este caso al entrar nosotros por el server spliteado
  194. verφamos al canal como ya creado, con los usuarios de nuestro mismo
  195. servidor (a los otros los "esconde" el split) y por tanto el server no nos
  196. darß el op, como es habitual al entrar en cualquier canal ya existente.
  197.  
  198.  TambiΘn hay que tener en cuenta que actualmente todos los servidores
  199. tienen protecciones anti-nethack. En este caso, al deshacerse el split, los
  200. restantes servidores te quitarßn el op a tφ en vez de ser al contrario
  201. (imponer tu op en los restantes servers), protegiendo al canal PERO Θsto lo
  202. harßn ·nicamente en caso de que ya hubiera ops en el canal antes de tu
  203. intento de net-hack (aunque hay veces en que el server se equivoca y
  204. mantiene tu op, quitßndoselo a los demßs). Es decir, que el net-hack
  205. funcionarß s≤lo para canales donde no haya op ("opless channels"). Por esta
  206. raz≤n, si queremos el op, necesitaremos tirar previamente a los ops
  207. (echarlos del canal, de forma que pierdan su op) para luego llevar a cabo
  208. el net-hack. ┐C≤mo tirarlos? De esto nos encargaremos mßs adelante, sigue
  209. leyendo };-)
  210.  
  211.  
  212. 2.3.- Otras formas de conseguir op.-
  213.  
  214.  La otra alternativa para conseguir el op es que alguien te lo de ;-) .
  215. Puede ser un op del canal o un irc-op de la red, aunque para esto ·ltimo
  216. tendrßs que dar una justificaci≤n convincente (como por ejemplo que os
  217. acaban de tomar el canal, alguien os ha atacado, Θtc).
  218.  
  219.  Para la primera alternativa entra en juego tu "don de la palabra": trata
  220. de hacerte amigo de alg·n op para que Θste te lo pase. En ese momento ya
  221. estßs capacitado para quitarle el op a todos los demßs ("mass-deop") y
  222. quedarte con el canal. Esto lo hacen automßticamente muchos scripts
  223. ("automatic-deop"): nada mßs darte el op el script automßticamente deopea a
  224. todos los ops (excepto a tφ, claro).
  225.  
  226.  
  227. 2.4.- Bot de servicio.-
  228.  
  229.  Se trata de un "usuario" muy especial... un robot que se encarga entre
  230. otras cosas de proteger los canales. En la red hispana se llama Scytale (en
  231. CobraNet, por ejemplo, es KingCobra) y estß dentro de muchos canales
  232. (registrados). Normalmente suele tener op, con lo cual el canal deja de ser
  233. opless y se evita el net-hack :-( Suele tener ircop-status [channel-service
  234. status] y ademßs tiene otras funciones en las que no pienso entrar.
  235. Resumiendo: si hay bot, nuestro gozo a un pozo.
  236.  
  237.  
  238.  
  239. 3.- Ataques.
  240.  
  241.  En esta secci≤n entraremos en materia... }:-)  Nuestro objetivo: tirar a
  242. alguien del server irc.
  243.  
  244.  
  245. 3.1.- Flood.-
  246.  
  247.  Los servidores IRC tienen que controlar el trßfico de entrada (el que
  248. proviene del exterior) para evitar su congesti≤n. Una de las formas de
  249. conseguirlo es no permitir que un cliente le mande mßs de una determinada
  250. cantidad de informaci≤n en un peque±o intervalo de tiempo; o lo que es lo
  251. mismo: la velocidad con que un cliente puede enviar datos al servidor estß
  252. limitada.
  253.  
  254.  Cuando un cliente supera el lφmite preestablecido por el servidor, Θste
  255. cierra la conexi≤n con el cliente: lo echa del servidor porque no puede
  256. soportar tanto caudal de entrada. El servidor lo "explica" asφ:
  257.  
  258. [1:59] *** _^TkLaS^_ has quit IRC (Excess Flood)
  259.  
  260.  Un flood, en general, no es otra cosa que mandar mucha informaci≤n en poco
  261. tiempo a alguien para intentar que se sature. Se puede floodear una
  262. direcci≤n IP, ..., o lo que ahora nos concierne: un servidor de IRC.
  263.  
  264.  La manera de aprovechar el flood en nuestro favor consiste en mandar
  265. muchas peticiones de informaci≤n a nuestra vφctima, de forma que Θsta, al
  266. contestar, supere el lφmite del servidor y Θste lo eche. Por ejemplo, si le
  267. mandamos muchos /ctcp version's seguidos (requiriendo informaci≤n sobre el
  268. programa cliente que estß utilizando) la vφctima floodearß al servidor
  269. cuando conteste porque mandarß muchas veces (tantas como peticiones haya
  270. habido) el texto de respuesta al servidor (para que del servidor vaya al
  271. cliente que peticion≤, i.e., al atacante).
  272.  
  273.  En esto del flood juega un papel muy importante el n·mero de peticiones
  274. que se reciben en un peque±o intervalo de tiempo. Cuantas mßs se reciban,
  275. mßs posibilidades hay de que el flood tenga Θxito. Por ello no es ninguna
  276. tonterφa mandar peticiones desde varios puntos a la vez, y no desde uno
  277. s≤lo, es decir, varios usuarios (íque podrφan ser una misma persona!) de la
  278. red IRC manden peticiones a la vφctima todos a la vez en un determinado
  279. momento. Si los usuarios (nicks) corresponden a una misma persona (una
  280. misma direcci≤n IP) se habla de clones. Por tanto, una posible forma de
  281. ataque serφa crearnos muchos clones y peticionar a la vez desde todos ellos
  282. a la vφctima.
  283.  
  284.  Pero los servidores tambiΘn suelen estar preparados para evitar muchos
  285. clones (cada clone ocupa, por decirlo de alguna manera, una "linea" de
  286. entrada al servidor, y esto consume recursos del mismo). Suele haber un
  287. mßximo permitido (en el irc hispano es 2) denegßndosele el acceso a la red
  288. a un tercer clone, o en caso de que Θste lo consiguiese expulsßndosele del
  289. servidor ("matßndolo") (el programa servidor revisa peri≤dicamente las IP's
  290. conectadas y detecta cuando hay varios usuarios con una misma direcci≤n
  291. IP):
  292.  
  293. [1:32] *** _^Virus^_ has quit IRC (Killed (Clones!))
  294.  
  295.  ┐C≤mo provocar un flood con mßs de 2 clones entonces? La respuesta es
  296. simple: en principio no se puede. ┐Entonces? Pues la soluci≤n es que varias
  297. personas distintas se pongan de acuerdo para atacar a la vez a la vφctima.
  298. Cada persona podrφa tener a su vez varios clones. Por ejemplo, si A
  299. (atacante) quiere atacar a V (vφctima), A se pone de acuerdo con B y C
  300. (otras 2 personas atacantes). A su vez supongamos que cada atacante tiene 2
  301. clones: i.1 e i.2 (donde i=A,B,C). Entonces tendremos 6 usuarios
  302. (conexiones IRC) distintos atacando a V, que serφan A.1, A.2, B.1, B.2, C.1
  303. y C.2. Pero hay un problema: ┐c≤mo sincronizarse para atacar? ┐C≤mo
  304. "ponerse de acuerdo" para mandar las peticiones en un determinado momento?
  305. Para esto existe lo que se denomina "floodnet" que, como habrß adivinado
  306. nuestro ßvido lector, es una "red" (asociaci≤n) de gente cuyo ·nico
  307. objetivo es floodear a alguien. La ventaja que tiene es que la
  308. sincronizaci≤n entre los distintos componentes de la floodnet es automßtica
  309. (lo hacen los scripts) lo cual resuelve el problema anterior. TambiΘn
  310. existe lo que se denomina "botnet" y que es anßlogo a la floodnet pero
  311. usando bots (no confundir con los "de servicio"; estos ·ltimos los ponen
  312. los servers de la red irc y no los usuarios) los cuales serßn lanzados
  313. desde alguna shell Unix (intΘrprete de comandos en una mßquina Unix). Los
  314. bots suelen estar prohibidos y cuando se detectan, a lo menos, son
  315. expulsados:
  316.  
  317. [1:32] *** Viernes13 has quit IRC (Killed (You are not welcome to this
  318. network!))
  319.  
  320.  
  321.  Hoy en dφa tanto los programas clientes de IRC como los scripts
  322. implementan protecciones anti-flood que dificultan enormemente el Θxito de
  323. un ataque de tipo flood. Por ejemplo, cuando detectan varias peticiones
  324. seguidas mandan las respuestas espaciadas en el tiempo (con pausas) y no
  325. inmediatamente, con lo cual se evita el flood.
  326.  
  327.  TambiΘn hay tΘcnicas de flood bastante optimizadas (por ejemplo, usando
  328. una floodnet) aunque en general un ataque flood no suele ser demasiado
  329. eficiente y es mßs costoso lograr su Θxito que con algunas de las tΘcnicas
  330. que se describen a continuaci≤n.
  331.  
  332.  
  333. 3.2.- Nick collide.-
  334.  
  335.  Un "nick collide" ocurre cuando dos personas tienen un mismo nick. En
  336. principio esto no deberφa ser posible (el servidor no deja usar un nick que
  337. ya estß en uso) pero hay dos situaciones en las que podrφa darse el caso y
  338. que se describen en los dos puntos siguientes.
  339.  
  340.  El resultado de un nick collide depende del servidor (ircd). En servidores
  341. antiguos (sin protecci≤n) el collide se resuelve matando a los dos usuarios
  342. con mismo nick (íambos!). En otros mßs inteligentes (con protecci≤n) el
  343. servidor guarda informaci≤n acerca de los usuarios y puede saber que
  344. usuario tiene el nick con mayor antigⁿedad (i.e. quiΘn se lo puso antes),
  345. matando ·nicamente al usuario con el nick mßs reciente (protegiendo al
  346. usuario mßs "veterano").
  347.  
  348.  
  349. 3.2.1.- Split server collide.-
  350.  
  351.  Se basa en aprovechar un net-split:
  352.  
  353.  - Esperar un split.
  354.  - Entrar (conectar) al servidor spliteado.
  355.  - Ponerse como nick el de la vφctima.
  356.  - Esperar a que se deshaga el split.
  357.  
  358.  Si todo va bien (el servidor no tiene protecci≤n), a la vuelta del split
  359. se detectarß el collide y se matarßn tanto al atacante como a la vφctima.
  360. L≤gicamente nuestro usuario atacante serß un clone nuestro, con lo cual no
  361. pasa nada si es killeado.
  362.  
  363.  
  364. 3.2.2.- Lag collide.-
  365.  
  366.  Consiste en aprovechar el lag de un servidor, o lo que es lo mismo, el
  367. retraso en recibir los mensajes de otros servidores. Esta tΘcnica es mßs
  368. efectiva que la anterior, pues funciona en servidores con protecci≤n.
  369.  
  370.  Los pasos serφan los siguientes:
  371.  
  372.  - Meter un clone en el servidor lageado.
  373.  - Esperar a que la vφctima cambie de nick (esto lo detectamos desde otro
  374. servidor no lageado).
  375.  - Cambiar rßpidamente el nick de nuestro clone y ponerle el que se acaba
  376. de poner la vφctima (el nuevo).
  377.  - Esperar al lag. ;)
  378.  
  379.  Lo que ocurre es que nuestra orden de cambiar el nick para nuestro clone
  380. llega antes al servidor (lageado) que la orden de cambio de nick de la
  381. vφctima debido a que nuestra orden va directamente de nuestro cliente al
  382. servidor lageado mientras que la otra va a travΘs de la red IRC (donde
  383. hemos supuesto que se introduce un lag notable). Esto hace que el servidor
  384. (lageado) tome a nuestro clone como "due±o" legφtimo del nick y mande un
  385. kill al otro (la vφctima). Esto ocurrirφa en caso de servidores protegidos;
  386. si es no protegido el resultado es que ambos mueren, resultado tambiΘn
  387. aceptable, pues hemos acabado con nuestro objetivo. };-)
  388.  
  389.  
  390. 3.3.- Nuke.-
  391.  
  392.  "Nuke" es la denominaci≤n genΘrica que se le suele dar a cualquier forma
  393. de ataque consistente en mandar paquetes arbitrarios a una determinada
  394. direcci≤n IP (no es que sea una definici≤n demasiado ortodoxa pero bueno...
  395. :)). Realmente el tΘrmino "nuke" siempre se ha referido al primero de los
  396. dos tipos que comentaremos, aunque aquφ se ha preferido tomar una
  397. definici≤n mßs amplia de dicha palabra.
  398.  
  399.  
  400. 3.3.1.- ICMP nuke.-
  401.  
  402.  El mßs veterano de los nukes [ :-) ] usa un protocolo subyacente de IP, el
  403. ICMP ("Internet Control Message Protocol": parte integral del protocolo de
  404. Internet [IP] que resuelve errores y controla los mensajes), para romper
  405. una conexi≤n cliente-servidor de IRC (tirar a alguien del server). Para
  406. entender c≤mo funciona hay que hablar un poco de protocolos; es aburrido
  407. pero no hay mßs remedio...
  408.  
  409.  Una conexi≤n IRC (cliente-servidor, que es lo que nos interesa) utiliza el
  410. protocolo TCP (nivel 4 [transporte] en la torre OSI), el cual se apoya
  411. sobre IP (nivel 3 [red]). IP se encarga, entre otras cosas, de hacer el
  412. rutado de paquetes ("datagramas IP"), es decir, dado un destino ir enviando
  413. los paquetes por el camino apropiado hasta alcanzar el host destino. TCP no
  414. ve nada de esto, tan s≤lo el destino directamente (manda los segmentos TCP
  415. directamente al destino), porque IP lo oculta (hace que el rutado sea
  416. transparente a TCP). L≤gicamente para que un protocolo de nivel superior
  417. funcione correctamente, tambiΘn deberßn hacerlo todos los que estΘn por
  418. debajo. En particular, para que nuestra conexi≤n TCP (IRC) se mantenga
  419. "viva", IP debe funcionar perfectamente. Y aquφ es donde interviene ICMP:
  420. se encarga de informar de posibles anomalφas que se han producido en el
  421. nivel 3 (IP), como por ejemplo, "host unreachable", que significarφa que no
  422. se ha podido alcanzar el host (el paquete IP ha ido dando saltos ["hops"]
  423. de un nodo a otro, hacia el destino, y ha llegado un momento en el que un
  424. determinado nodo intermedio no sabφa quΘ hacer con Θl o ha expirado el
  425. tiempo de vida de dicho paquete). En este caso, el paquete que informa del
  426. error (ICMP) lo envφa el nodo intermedio que se ha dado cuenta del error
  427. hacia el "remitente" que lanz≤ el paquete original (que no se ha podido
  428. entregar a su destinatario). Los mensajes ICMP se situan dentro del campo
  429. de datos de un datagrama IP y se envφan exactamente igual que si fueran
  430. datos IP (no son prioritarios). No es objetivo de este escrito tratar mßs a
  431. fondo este tema (para los interesados les aconsejo el libro
  432. "Internetworking with TCP/IP, vol I", de Douglas E. Comer, disponible en
  433. castellano ya en su tercera edici≤n).
  434.  
  435.  Resumiendo: mediante ICMP informamos de que IP ha fallado, y por tanto,
  436. tambiΘn los niveles superiores como TCP.
  437.  
  438.  Comprendiendo lo anterior ya se puede intuir en quΘ consiste el ICMP nuke:
  439. mandar mensajes ICMP falseados, enga±ando al destino, haciΘndole creer que
  440. el otro extremo ha detectado un error y por tanto, provocando un "cierre"
  441. de la comunicaci≤n. Vamos a explicar un poco mejor Θsto.
  442.  
  443.  En una conexi≤n siempre tenemos dos extremos, lo que da dos posibilidades
  444. a la hora de enga±ar, seg·n lo hagamos  a uno u otro. En el caso de una
  445. conexi≤n IRC, podemos llevar a cabo dos formas de ataque:
  446.  
  447.  * Server nuking (nukear al server): los mensajes ICMP se mandan al
  448. servidor IRC, haciΘndole creer que se ha producido un error al intentar
  449. comunicarse con el cliente. Como respuesta a este mensaje el server cierra
  450. la conexi≤n que tenφa con dicho cliente. El efecto producido es la
  451. "expulsi≤n" del usuario por parte del servidor.
  452.  
  453.  * Client nuking (nukear al cliente): esta vez se envφan los ICMP's al
  454. cliente; Θste cree que el servidor no estß disponible y cierra la conexi≤n
  455. (el cliente). El servidor no sabe nada en principio, pero detecta el cierre
  456. de conexi≤n por parte del cliente, dando el correspondiente error y
  457. cerrando tambiΘn la conexi≤n por su parte.
  458.  
  459.  En teorφa las dos fomas de nuking son perfectamente vßlidas y eficientes,
  460. aunque hay que tener ciertas consideraciones en cuenta, como son:
  461.  
  462. - tanto servidor como cliente pueden tener protecci≤n anti-nuke y puede ser
  463. necesario atacar uno porque el otro estΘ protegido (ver mßs adelante).
  464. - si atacas a un cliente, Θste puede detectar quiΘn le estß atacando con un
  465. simple analizador de paquetes IP o tracer, y tambiΘn podrφa responder con
  466. otro ataque de este o cualquier otro tipo (cuidado con quiΘn te metes ;-)).
  467.  
  468. - si atacas al servidor, el cliente no tiene manera de saber quiΘn le ha
  469. "atacado" porque los mensajes ICMP no le han llegado a Θl sino al servidor
  470. (ventaja); pero por otro lado, el servidor sφ sabe quiΘn ha hecho el ataque
  471. y puede resultar en una K/G-Line a dicho usuario por parte del servidor (el
  472. usuario podrφa ser baneado de toda la red de IRC).
  473. - los inconvenientes de los dos puntos anteriores pueden ser solventados
  474. falseando la direcci≤n origen de los mensajes ICMP que se envφan. Esta
  475. tΘcnica se conoce como "spoofing" (ver punto 4).
  476.  
  477.  Hay diversos tipos de error ICMP que se pueden utilizar a la hora de hacer
  478. un nuke. En cuanto a la informaci≤n prßctica de c≤mo utilizar un nuker
  479. (programa "nukeador"), debemos tener en cuenta que ademßs de suministrarle
  480. el tipo de error que se desea producir, juegan un papel muy importante los
  481. puertos, tanto origen como destino, que se elijan.
  482.  
  483.  Una conexi≤n IRC (TCP) queda definida unφvocamente por los pares direcci≤n
  484. IP origen-puerto origen y direcci≤n IP destino-puerto destino. Estos datos
  485. son los que hay que suministrarles al programa nukeador. Puertos tφpicos
  486. del servidor de IRC (serß el puerto destino en caso de server nuking o el
  487. fuente si se trata de un client nuking) son 6665-9,  4400-6, 7000 y 7777.
  488. En realidad cada servidor IRC tiene unos puertos oficialmente reconocidos
  489. (que son conocidos p·blicamente: los podemos leer en el motd ["mensaje del
  490. dia"] al entrar en el IRC) y otros que podrφamos denominar como privados, y
  491. que se usan por ejemplo para las conexiones entre los distintos servidores
  492. que forman la red. Un usuario puede estar usando uno de estos puertos
  493. "fantasmas" (aunque el servidor tambiΘn puede limitar el acceso a estos
  494. puertos) para esconderse de nukes, puesto que necesitamos conocer este dato
  495. para que el nuke sea efectivo.
  496.  
  497.  TambiΘn necesitamos conocer el puerto del cliente, aunque esto es mßs
  498. difφcil porque varφa mucho (no son fijos como en el caso anterior)
  499. dependiendo del sistema operativo que estΘ corriendo dicho cliente, los
  500. puertos que ya tuviera ocupados antes de establecer la conexi≤n IRC, Θtc.
  501. Lo normal es hacer un barrido de estos puertos empezando por el 1024 (hay
  502. puertos que por convenio siempre se asignan a determinadas tareas y no se
  503. pueden usar arbitrariamente con lo cual no necesitamos barrerlos) y
  504. acabando en 4000, por ejemplo, aunque podrφa ser necesario aumentar este
  505. n·mero.
  506.  
  507.  Es tambiΘn muy ·til utilizar un "port-scan": programa que va probando los
  508. distintos puertos de una direcci≤n IP (destino) dada e informa de la
  509. respuesta recibida para cada uno de  dichos puertos (asφ podemos saber, por
  510. ejemplo, quΘ puertos de un servidor estßn dedicados a aceptar conexiones
  511. IRC).
  512.  
  513.  A continuaci≤n transcribo mensajes tφpicos de salida de nuestras
  514. potenciales vφctimas en una sesi≤n tφpica de IRC:
  515.  
  516. [1:42] *** aRmiTaGe has quit IRC (Read error to
  517. aRmiTaGe[ig-183.arrakis.es]: Connection reset by peer)
  518. [1:13] *** KoNtRoL has quit IRC (Read error to KoNtRoL[195.76.99.76]: EOF
  519. from client)
  520. [3:17] *** BrOKeNn has quit IRC (Read error to BrOKeNn[194.224.57.171]:
  521. Protocol not available)
  522. [5:25] *** Eli has quit IRC (Read error to Eli[info760.jet.es]: Network is
  523. unreachable)
  524. [5:26] *** Eli has quit IRC (Read error to Eli[info760.jet.es]: Machine is
  525. not on the network)
  526. [4:20] *** vp has quit IRC (Read error to vp[ia-176.arrakis.es]: Connection
  527. refused)
  528. [2:41] *** Estrayk has quit IRC (Read error to Estrayk[ctv3011.ctv.es]: No
  529. route to host)
  530.  
  531.  La protecci≤n anti-nuke, a grosso modo, pasa por ignorar los mensajes ICMP
  532. que lleguen, aunque Θsto ya estß limitando el propio funcionamiento del
  533. protocolo IP, en el sentido de que ICMP es parte integrante de IP y no se
  534. deberφa inhibir (┐quΘ ocurrirφa si llega un mensaje "de verdad" y es
  535. ignorado?). Se puede llevar a cabo mßs o menos "finamente": por ejemplo
  536. descartar solo los ICMP's de un tipo y no todos los posibles. Se podrφa
  537. lograr con un firewall (software o hardware encargado de filtrar los
  538. paquetes provinientes de la red en base a una reglas previamente definidas)
  539. convenientemente configurado.
  540.  
  541.  
  542. 3.3.2.- OOB nuke.-
  543.  
  544.  TambiΘn conocido como 'winnuke', ya que afecta s≤lo al sistema operativo
  545. Windows, en cualquiera de sus "sabores": 3.x, 95 y NT. Se basa en un bug
  546. que tiene este SO en la pila de protocolos por el cual el sistema se cuelga
  547. ("error de protecci≤n general...blah, blah...") cuando recibe un paquete
  548. con el flag OOB ("Out of band") activado. El ataque es sencillo: mandar un
  549. paquete de este tipo a un puerto (normalmente el 139) de nuestrß vφctima
  550. (Θsta debe estar corriendo Windows, lo cual es muy normal hoy en dφa).
  551. Existen programas ya hechos a los cuales simplemente le das la direcci≤n IP
  552. de la vφctima y el programa lo hace todo.
  553.  
  554.  La forma de protegerse es cerrar los puertos por los que nos puedan atacar
  555. (el 139 principalmente) o aplicar alg·n parche al SO para quitarnos el bug.
  556. Otra soluci≤n menos recomendable es la que llevan a cabo algunos ISPs
  557. (proveedores de Internet), y que consiste en filtrar todos los paquetes
  558. dirigidos al puerto 139 (inconveniente: nos estßn  dejando inoperativo ese
  559. puerto). Hoy en dφa es muy popular este bug y normalmente estß ampliamente
  560. parcheado (aunque siempre habrß alg·n que otro despistado que no lo tenga
  561. instalado }=)).
  562.  
  563.  Como hemos dicho, este ataque no s≤lo consigue echar a la vφctima del
  564. server sino que ademßs le deja colgado el ordenador (tendrß que hacer un
  565. reboot), lo que lo hace especialmente peligroso. La vφctima saldrß del IRC
  566. con un mensaje de tipo ping-timeout como:
  567.  
  568. [19:56] *** Goku has quit IRC (Ping timeout for
  569. Goku[system.tech.arrakis.es])
  570.  
  571.  
  572. 3.4.- Ping.-
  573.  
  574.  Algunos los llama tambiΘn "IP bombs" (bombas IP). Un ping es un tipo de
  575. mensaje ICMP que se usa para ver si una mßquina se encuentra operativa y
  576. accesible. El procedimiento es enviarle un ping a la mßquina; Θsta lo
  577. recibe y contesta. Al recibir la contestaci≤n ya sabemos que la mßquina
  578. vive. Si no se recibe en un plazo dado se considera como no accesible (la
  579. mßquina podrφa estar apagada, o todos los "caminos" en la red hacia ella
  580. cortados). Ademßs podemos obtener mßs datos como el grado de saturaci≤n de
  581. una mßquina o red (midiendo el tiempo de respuesta de la mßquina, es decir,
  582. el tiempo transcurrido desde que una mßquina origen envφa el ping hasta que
  583. recibe la contestaci≤n de la otra).
  584.  
  585.  La manera de usar esto de forma ofensiva consiste en mandar mßs pings a un
  586. usuario de los que su mßquina pueda contestar, saturßndole su conexi≤n a
  587. Internet. Por tanto se debe de hacer desde un enlace mßs potente que el que
  588. pretendemos atacar.
  589.  
  590.  Lo tφpico es que la vφctima estΘ en su casa y tenga un modem. Por tanto,
  591. necesitamos una conexi≤n a inet mßs rßpida que eso. Lo normal es atacar
  592. desde una mßquina ubicada ya en la red (conectada mediante ATM, FDDI, ...).
  593. Por ejemplo, puede valer la cuenta de la Universidad ;-). La forma de
  594. hacerlo serφa abriΘndonos un shell y tecleando:
  595.  
  596.   $  ping -s 32000 <direcc. IP>
  597.  
  598. (la sintaxis puede variar ligeramente seg·n sistema operativo).
  599.  
  600.  Los paquetes que se envφan al hacer ping son tφpicamente muy peque±os. Con
  601. el modificador   -s estamos forzando un nuevo tama±o (32000 bytes es
  602. aceptable; tambiΘn podeis probar con 64000).
  603.  
  604.  Pensad: un modem de 28.8 tardarß unos 18 segs. en recibir 64 Kbytes (sin
  605. considerar compresi≤n), mientras que desde nuestra shell lo hemos mandado
  606. en íídΘcimas de segundo!! Si consideramos ademßs que el comando ping manda
  607. mßs de un paquete (los que queramos) ... íboom! TendrΘis el modem de
  608. vuestra vφctima trabajando a toda pastilla para nada y fastidißndole todo
  609. lo que estΘ haciendo. En particular, le estropearΘis su conexi≤n al IRC: en
  610. el mejor de los casos la vφctima tendrß un lag horroroso y el peor serß
  611. expulsada del servidor por "ping time-out".
  612.  
  613.  
  614. 3.5.- Ssping.-
  615.  
  616.  Nos encontramos ante otro bug parecido al del OOB, que afecta a Win95 y NT
  617. (aunque no a todas las configuraciones), y cuya idea es que el
  618. "maravilloso" Windows "se lφa" a la hora de reconstruir paquetes que le han
  619. llegado fragmentados y acaba con un cuelgue del ordenador. El ataque
  620. consiste en precisamente mandar esos paquetes fragmentados a la vφctima.
  621.  
  622.  Un bug de este tipo es viejo conocido de los sistemas UNIX (el ataque se
  623. conocφa como "ping of death"); pero la novedad es que ahora lo sufren los
  624. Windows. Aunque son cosas tΘcnicamente diferentes, la forma de proceder a
  625. la hora de atacar es anßloga a OOB: solo hay que saber la direcci≤n IP de
  626. la vφctima y íboom!: le dejamos colgado el ordenador.
  627.  
  628.  La soluci≤n pasa por parchear el S.O. En particular, este bug parece que
  629. no afecta al Trumpet Winsock asφ que si lo usais estareis protegidos.
  630.  
  631.  
  632.  
  633. 4.- Spoofing.
  634.  
  635.  Esta tΘcnica no es un ataque en sφ pero permite mejorar y perfeccionar
  636. cualquier ataque (de los anteriores, por ejemplo). TambiΘn puede ser la
  637. base de alg·n ataque, como ocurre con el IP Spoofing que los hackers suelen
  638. emplear (me desviarφa del tema  de este escrito si siguiese
  639. escribiendo...).
  640.  
  641.  Se trata de "spoofear" (=falsear) la direcci≤n IP de origen de los
  642. paquetes que se mandan a la vφctima, de forma que Θsta crea que el origen
  643. de dichos paquetes es otro (el que nosotros le indiquemos). De esta forma
  644. protegemos nuestro anonimato, y en general podemos llevar a cabo cualquier
  645. acci≤n que se nos pueda ocurrir y que se derive de una falsa direcci≤n
  646. source (origen). Por ejemplo, podemos nukear a alguien, con la direcci≤n
  647. fuente de otro, haciendo creer a la vφctima (si Θsta tiene un analizador de
  648. paquetes o algo parecido) que es el otro el que le estß atacando }:-).
  649.  
  650.  El spoofing es (o podrφa ser) una funcionalidad mßs del programa de ataque
  651. (del nuker, del ping, ...). Como consiste en manejar IP desde un muy bajo
  652. nivel en muchos casos se requieren privilegios especiales. Por ejemplo, en
  653. el caso de mßquinas Unix, se necesita abrir "raw sockets" y Θsto requiere
  654. de privilegios de superusuario (root).
  655.  
  656.  
  657.  
  658. 5.- Resources.
  659.  
  660.  Este apartado estß dedicado, brevemente, a los distintos programas
  661. disponibles y ·tiles a nuestra causa :-).
  662.  
  663.  Por ahora s≤lo incluyo la siguiente URL:  http://www.7thsphere.com/virus.
  664. Allφ podrßs encontrar toda clase de utilidades para Windows y Linux:
  665. programas nukeadores, port-scanners, Θtc...
  666.  
  667.  
  668.  
  669. 6.- Agradecimientos.
  670.  
  671.  Quisiera dar las gracias a jcea@argo.es por echarle un vistazo a este
  672. texto y por sus comentarios desinteresados sobre Θl.
  673.  
  674.  
  675.  
  676. 7.- Notas finales.
  677.  
  678.  Espero que este peque±o artφculo os haya servido al menos para comprender
  679. un poco mßs el funcionamiento del IRC.
  680.  
  681.  TambiΘn me gustarφa recordar que el IRC no es un campo de batalla, y que
  682. no se debe atacar a la gente asφ porque asφ, salvo "en defensa propia" y
  683. pocos casos mßs justificados. O:-)  En cualquier caso un ataque nunca estß
  684. justificado desde el punto de vista de los ircops, asφ que cuidado con las
  685. K/G-lines ;-)
  686.  
  687.  Por ·ltimo, decir que este artφculo es la primera versi≤n y que pudiera
  688. contener numerosos errores asφ como alg·n que otro "punto negro". Se
  689. agradecerφa toda clase de comentarios y sugerencias para mejorar el
  690. documento: bug reports, asuntos que creßis no estßn bien explicados, temas
  691. que faltan y se deberφan incluir, ..., y en definitiva todo lo que os
  692. gustarφa que se incluyese en el documento. TambiΘn se aceptan O-lines ;-)
  693.  
  694.  Podeis contactar con el autor de este escrito por email:
  695. roman@deathsdoor.com. O localizarme en el IRC hispano bajo el nick de
  696. RoMaNSoFt.
  697.  
  698.   c'U l8er!!!!!
  699.  
  700. _______________________________________________________________________________________________
  701.  
  702. La distribuci≤n de este documento es "libre", con la ·nica condici≤n de
  703. informar al autor en caso de subirlo a alg·n ftp site o pßgina web. La
  704. misma restricci≤n se aplica a cualquier otra forma de difusi≤n p·blica
  705. (revistas, news, Θtc).
  706. ###############################################################################################
  707. ---------------------------------------------------------------------------
  708.  
  709. * Este documento se encuentra disponible en versi≤n WordPad en la secci≤n
  710. de software.
  711.  
  712.  Ya puedes volver a la home page.
  713.  
  714. ---------------------------------------------------------------------------
  715. (c) RoMaN SoFt / LLFB, 1997.- (·ltima modificaci≤n de este fichero:
  716. 30/07/97)
  717.  
  718.